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(54) Scalable interactive multimedia server system 

(57) Connects a host computer system (such as a 
mainframe or host server system) to a large mult.med.a 
TmM) distribution network having wide scalabilrty 
out being limited by bandwidth constants in the host 
"stem or in any multimedia controller for controlling on 
demand" viewing of movies at a > large numbe of set- 
top-boxes (STBs) with TV sets. Connected to the host 
system is Network distribution arrangement composed 
of a plurality of multimedia (MM) adapters, each MM 
adapSr containing a plurality of MM controllers, each 
Controller being connected to a multiplicity of MM 
pairs, each MM pair being connected to the netwo k for 
controlling a direct distribution of mov.es to a large 
numbe St STBs. Each MM pair includes a disk adapter 
anfanetwork adapter connected by a common MM 
Pair bus for transmitting disk data blocks directly < tc , the 
STBs The disk adapter controls and receives data from 
one or more disk devices. The network adapter sends 
^ cSkdata to the network. In each MM pa, a pa, bus 
connects the network adapter to transmit data from the 
£k adapter to the network. Data fHes (movies) are 
stored on the disks, and any file can be selected by an 
ITbIo? transmission to the STB. Data blocks are read 
Meetly from the disk to the pair bus and *er , dir^iy 
through the network to the requesting STB. Any _ STB 
may issue interactive commands to control a data file 
while it is being received. 
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Description 

Introduction 

The invention allows a host computer system (such 5 
as a mainframe or host server system) to control a mas- 
sive multimedia (MM) distribution system without being 
limited by bandwidth constraints in the host system. 
This invention enables a very large number of data 
users using network-connected devices (set-top-boxes w 
STBs, with TV sets) to independently interact with the 
MM system in receiving requested data (e.g. movies). 

Background of the Invention 

15 

Public interest desires multimedia movies "on 
demand". But current data distribution systems are 
inadequate to handle mass distribution on demand. The 
"on demand" requirement means the distribution sys- 
tem must allow simultaneous independent and non-syn- 20 
chronous user selection and distribution of movies, 
allow each user to have independent control over recep- 
tion of each requested movie. 

Current computer systems can store large numbers 
of movies on tape, a smaller number of movies on fast 25 
access disk storage, and an even smaller number of 
movies in a computer's random access main storage. A 
single movie (which is a data file) may require 4 Giga- 
Bytes of digital data storage for its sound and video. 

Current centralized movie distribution systems do 30 
not economically support massive simultaneous inde- 
pendent user viewing and control, and they do not eco- 
nomically compete with commercial VCRs (video 
cassette recorders). 

Current transmission networks supporting large 35 
numbers of user devices (e.g. TV sets) only transmit 
unidirectional, and support synchronous transmission 
of movies. A single copy of a movie is transmitted to all 
TV sets, and no user control over the transmission is 
allowed, other than turning on/off of the reception of 40 
each movie. The lack of "on demand" viewing applies to 
both current airwave and cable TV systems. 

Current computer-controlled "on demand" distribu- 
tion systems have been proposed and tried, but they 
lack the ability to economically support mass "on 45 
demand" public viewing. A fundamental problem with 
such current systems is that they funnel all transmitted 
data through a single memory (usually a system "main 
memory" of a computer system), and such main mem- 
ory buffer is a bottleneck to economical mass distribu- so 
tion. 

For example, this is generally done by a computer 
reading blocks of data serially (one at a time) from a 
disk through an I/O subsystem into the computer's main 
memory, and then transmitting the blocks serially (one ss 
at a time) from the main memory to the network for dis- 
tribution to the STBs. Each movie may have a single 
buffer in main memory from which each block is sent 
simultaneously and synchronously to ail STBs which 
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previously ordered the same movie (such as by tele- 
phone from an available movie schedule list). 

Thus, each buffer transmits its content simultane- 
ously to the TV network transmitting to all STBs which 
had scheduled the movie transmission. This synchro- 
nous transmission of each movie requires all requesting 
customers to start viewing the movie at the same time 
and to receive the same identically transmitted data of 
the movie. This is a "synchronized transmission" of one 
copy of each movie. 

"On demand" viewing requires "non-synchronized 
bidirectional transmissions" for all interactive viewers of 
movies, in which each user controls his/her movie view- 
ing independent of all other viewers - similar to user 
viewing currently obtainable with a VCR. "On demand" 
viewing applies to al! viewers whether they are viewing 
the same or different movies. Many problems are 
involved with providing simultaneous independent non- 
synchronized bidirectional transmissions for all viewers. 

Continuous viewing must be maintained for each 
viewer (no apparent transmission breaks in viewing) for 
the "on demand" distribution, except as commanded by 
each viewer using VCR-like controls such as START, 
STOP, REWIND, FAST-FORWARD, PAUSE, etc. while a 
movie is being viewed. 

Conventional on-demand TV movie viewing for a 
limited numbers of viewers using Set Top Boxes (STBs) 
on a network use a host computer system. A selection 
menu table of movies in the host system is used by all 
users to independently select any movie in the menu. 
When a viewer selects a movie, a request is sent from 
his STB through the network to the host computer sys- 
tem for customer authorization, including customer vali- 
dation and accounting functions, prior to starting 
transmission of the movie to the requesting viewer. 
Also, the host system locates a copy of the requested 
movie on a tape or disk drive. If the movie is found on 
tape, it may be transferred to a disk drive, which gener- 
ally can provide better control over the network trans- 
mission process than can be obtained from a tape drive. 
The data is first read from the disk through an I/O sub- 
system (IOSS) into main storage, and then the data is 
read from main storage through an IOSS to a network 
adapter that connected to the network of the requesting 
STB. The network includes switching functions that 
receive a command from the host computer system to 
connect the network adapter to the requesting STBs. 
The host system checks the requesting STB's authori- 
zation. 

The number of movies the conventional host sys- 
tem can concurrently supply is mostly limited by the bus 
bandwidth available for transmitting the independent 
movies to the requesting STBs. The independent cop- 
ies of the transmitted movies (whether the same or dif- 
ferent movies) compete for the memory bus bandwidth. 
Only one block of one movie can be transmitted on the 
memory bus at any one time. 

Each movie being sent to a viewer requires a band- 
width of 0.2-0.5 megabytes per second (MB/s) of data 
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transmission. In prior host/network transmission sys- 
tems, ail blocks of data must be read from disk through 
the IOSS, and written into the computer's main storage. 
Later, the blocks are read out of main storage through 
the IOSS to the network. Consequently, the prior host 
computer system had to twice move the movie data 
(once from disk, and once from main memory) in deliv- 
ering the movie to the viewer. 

However, other buses, which are serially connected 
to the memory bus, such as I/O buses, may put a severe 
constraint on the maximum number of independent 
movies which can be concurrently transmitted "on 
demand" to requesting STBs by conventional computer 
systems. An example of such a prior host computer sys- 
tem uses an IBM RS/6000 model 59H RISC host sys- 
tem. This system has 16 adapter slots on 2 
microchannel buses for connecting adapters to a RISC 
processor. The 1 6 slots of the M59H system are equally 
divided between disk adapters and network adapters. 
Each adapter can handle a bandwidth of up to 10 MB/s. 
When designing the system to deliver movies from 
disks to a network through main memory, the total disk 
adapter bandwidth and the total network bandwidth 
were considered. At 4 GBs of memory storage per 
movie, and the high cost of memory storage, very few 
movies, could be delivered from memory storage by this 
prior art system. 

When determining how many movies a host system 
can deliver, each transmission component of a system 
must be evaluated for possible bottlenecks. In the 
RS/6000 model 59H system, a continuous viewing 
capability at each requesting TV set is maintained by 
transmitting each movie on the network at an average 
0 2-0.5 MB/s data rate. If each corresponding disk oper- 
ates at the 2.0 MB/s rate with a disk adapter having a 1 0 
MB/s bandwidth, the disk adapter (in the RS/6000 
M59H) could support up to 5 disk drives operating 

simultaneously. KAtze , LJ 
However, the bandwidth bottleneck in the M59H 
system is its two microchannel buses because each 
have only a bandwidth of 20 MB/s. In this example one 
microchannel bus is attached to disk adapters and the 
other microchannel bus is attached to network adapt- 
ers Since each microchannel bus has only 20 MB/s of 
bandwidth, each microchannel bus then can support 
only 10 disks operating simultaneously at the 2.0 MB/s 
rate Thus each microchannel can support only 2 disk 
adapters operating at 10 MB/s and consequently 2 net- 
work adapters. 

In the M59H example the system bottleneck is the 
microchannel buses and the system can concurrently 
handle a maximum of 40-100 movie requests, whether 
the transmission is supported by an on-demand proto- 
col or a synchronous protocol in which all requesting 
STBs being serviced are simultaneously receiving the 
same data without any interactive means available. 

Figure 2 represents the above described example 
of the prior art bottleneck in a multimedia data server 
computer system, using two separate I/O transmission 



paths through its main memory buffer to obtain I/O syn- 
chronization. Thus, it transmits data from disks 107 
through its system main memory to network 108. Each 
of these two I/O paths requires a separate CPU com- 
5 mand. The first command controls the transmission of 
the disk data along the first path comprising one of disks 
1 07. a connected disk adapter 201 , a connected I/O bus 
105, IOSS 104, system memory bus 103 into main 
memory 102, where the transmitted data is stored in a 
w respective buffer. Then, a second CPU command con- 
trols a transfer of the data from main memory to an 
assigned network adapter 202, which is connected to 
network 108. A program running in CPU 101 issues 
these I/O commands which control the transmission of 
15 all movies from the disks 1 07 to requesting STBs con- 
nected to network 108. 

In any prior art server computer, the data being 
transmitted from disk to main memory may encounter a 
bandwidth constraint at any internal component through 
20 which the data passes, such as I/O bus 1 05, IOSS 1 04, 
or the system memory bus 103. Because the data must 
travel both into and out of main memory, internal com- 
puter bandwidth requirements are double the movie 
data rate requirements of 0.2-0.5 MB/s. Different prior 
25 art server designs may have different points at which 
their internal resources have bandwidth constraints, lim- 
iting the number of movies which may be served at the 
same time. 

In this example, the RS/6000 M59H system mem- 
30 ory bus has 300 MB/s of bandwidth of which only 40 
MB/s of the bandwidth can be utilized for the movie 
transmission operation. Accordingly, the bottleneck in 
the M59H system is its microchannel's maximum band- 
width of 40 MB/s. Its excess bandwidth of 260 MB/s 
35 cannot be used for movies and is wasted unless used 
for unrelated central processing operations. 

When any prior computer system is used as a mul- 
timedia server that buffers movie transmissions through 
its main memory, it will have similar bottlenecks. Differ- 
40 ent prior computer systems have different bottleneck 
limitations which must be specifically evaluated by com- 
puter server designers. 



Summary of the Invention 
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The invention eliminates the prior bottleneck 
caused to "on demand" network transmission by band- 
width limitations of system memory buses and associ- 
ated buses. The invention eliminates bandwidth 
so limitations caused by transmitting movie data (and simi- 
lar text/graphic data) through system memory buses 
and associated buses. Yet, the invention allows a host 
computer system to retain control over all movie trans- 
missions in a large movie distribution network while 
55 relieving the host computer from transferring any movie 
data. The movie network transmission capability is not 
constrained by any host bus bandwidth limitation. 

This invention also enables scalability of a multime- 
dia system by enabling a single host computer system 
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to support whatever number of the set-top-boxes 
(STBs) may make simultaneous requests for "on 
demand" movie transmissions. 

Further, this invention enables the host system's 
resources to remain free of network data, so that the 
host resources are able to be used by the host compu- 
ter system for other purposes, as well as for controlling 
the network operations. As a consequence, this inven- 
tion allows the number of concurrent movies being 
played to be expanded by at least an order of magnitude 
and more likely by plural orders of magnitude, and con- 
ceivably can support thousands of STBs supportable by 
a single host system. 

To do this, the invention removes network data han- 
dling operations from the host system. Only network 
control operations are retained by the host system over 
network data transmissions. The invention provides a 
control hierarchy having one or more multimedia (MM) 
adapters, each containing one or more multimedia con- 
trollers (MMC) to exercise further control over the net- 
work data transmission operations. Each MMC 
connects to a plurality of "MM pairs" which directly 
transmit the data from selected disks to the network. A 
scalable (expandable) number of MM pairs are sup- 
ported by one MMC. The scalability of MM pairs is fur- 
ther expandable by allowing any number of MMCs to be 
operated by a single MM Adapter. The scalability of MM 
pairs is still further expandable by allowing any number 
of MM Adapters to be connected to a single host sys- 
tem. 

Each MM pair has a "pair bus" which directly con- 
nects the multimedia disk adapter to a multimedia net- 
work adapter in the pair. The MM network adapter 
connects the pair bus to a network having a large 
number of requesting STBs. Thousands of STBs may 
be controlled by a single host computer system having 
a MMC controlling a plurality of MM pairs (with their plu- 
rality of pair buses). The host system is not unduly bur- 
dened by being relieved of transmitting network data, 
and the computer system may be doing unrelated work 
during most of its operational time, and its internal 
buses present no constraint on the number of movies 
that may be handled by the network on an "on demand" 
basis. 

Each conventional STB has an internal buffer for 
receiving a data block from the network, and for control- 
ling the outputting of the data from the buffer to an 
attached TV set The network block transmission rate is 
much faster than the STB buffer output rate, so that 
each data block is received into a STB buffer in a frac- 
tion of the time that the data in the block is consumed by 
user viewing of the movie on a TV set. 

But the STBs and networks transmit both data and 
control signals to their assigned MMC through their MM 
pairs. Control commands are generated by the STBs 
and sent through the network to the MMC when the STB 
wants or needs service. 

The MMC contains control logic in the form of a MM 
control microprocessor and MM control memory. Movie 
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data does not pass through the MM control memory. 
The MM microprocessor and MM memory are only 
used to control the data passing through connected MM 
pairs. A relatively high limit exists for the maximum 
5 number of movie transmissions which may be handled 
by any one MM pair bus by interleaving multiple movie 
block transmissions through the bus in a serialized man- 
ner. 

Host network control processing (NCP) is handled 

10 by a network control system which may be a program 
running in the host system, which receives each user 
request from the MMC for a movie transmission. The 
NCP determines: STB authorization to receive movies, 
which of plural MMC controlled disks has each 

is requested movie, and the NCP executes other prelimi- 
nary processes before a user request from an STB can 
be allowed to receive a movie transmission. 

The MM command protocol involves having the 
MMC receive each STB start command containing a 

20 request for STB reception of an identified movie. The 
MMC passes the request to the host system to perform 
its processing. If the host system approves the request, 
it assigns a host CPU to send a CPU command to the 
MMC (which may be the same MMC which sent the 

25 request to the host, but the CPU command may be sent 
to any MMC controlled by the host system having a MM 
pair connectable to the requesting STB and having a 
disk containing the requested movie). 

The movie start command from an STB enables the 

30 host CPU to determine user authorization, and if the 
user is authorized the host selects the disk containing 
the requested movie, sends a host command to an 
MMC to start the transmission through a selected MM 
pair. While viewing the movie, the STB may interactively 

35 send to the MMC new STB commands including 
START, STOP, REWIND, FAST-FORWARD, PAUSE, 
etc. to control the movie transmission to provide VCR 
functions similar to the TV control functions found with 
current commercial tape VCRs. 

40 All STB commands pass through the network to an 
assigned (connected) MM pair, which passes the STB 
command to its MMCs microprocessor which then 
processes or passes the command to the host compu- 
ter system. The MMC handles commands which do not 

45 require NCP processing in the host. 

The bandwidth of the pair bus in each MM pair is 
designed to be larger than the bandwidth of the con- 
nected paired disk adapter or paired network adapter. A 
bandwidth matched to the adapters is needed to enable 

so an unconstrained flow of interleaved data blocks from 
reading disks attached to the disk adapter, through the 
MM pair bus and its connected network adapter, to the 
network and the requesting STB. The data blocks in this 
transmission path do not pass through the MMC or the 

55 host computer system, and their transmission is not 
affected by any bandwidth constraints in either the MMC 
or host system. 

Once a movie transmission is started to a request- 
ing STB, the STB automatically maintains a continuous 



4 



>: <EP 07461 58A2J_> 



EP 0 746 158 A2 



8 



w 



15 



20 



25 



transmission of the movie for smooth TV viewing of the 
movie data by issuing a series of next block commands 
to the MM controller (transparent to the human user of 
the STB) The STB buffers each received data block, 
and performs any decoding, cryptography, metering, . 
and control function as it outputs the STB buffered data 
to the attached TV set for viewing and sound. After the 
MMC processor receives the CPU command for starting 
the movie, it sets a flag field in the MMC memory indi- 
cating the authorization for this transmission so that the 
MMC processor can directly handle the processing 
needed to send a data block responding to the STB 
command without involving the host system in the 
processing of the next block commands. In this manner, 
the MMC processor, MMC pair, and STB cooperate to 
continue the data block transmissions until the entire 
movie is transmitted. 

The STB generates a next block command when- 
ever it senses its data buffer is soon to become empty of 
data Then the STB sends a next block command con- 
trol block and an interrupt signal to its connected MM 
adapter in time to allow for MMC processing the com- 
mand to get the next data block of the movie early 
enough to maintain uninterrupted viewing on the TV set 
attached to the requesting STB. The STB s next block 
command contains at least: an identifier of he 
requested movie, and the network address of the 

requesting STB. 

When the MM processor services the next diock 
command, the MM processor responds by sending a 
pair of MM control commands to the associated MM 
pair- including a disk read command to the disk adapter 
and a network control command to the network adapter. 
The disk read command contains the disk address of 
the identified movie and the block address on the disk of 
the next data block to be read from the disk. The net- 
work control command contains a path address that 
locates a path through the network to the requesting 
STB which is to receive this next data block being trans- 
mitted. , .... 

The path address may use a path protocol which is 
interpreted in the network, for each block being trans- 
mitted through the network. For this protocol, the MM 
processor inserts path information into a prefix concate- 
nated with each next data block to be transmitted by the 
network adapter. The prefix contains the path identifiers 
that enable each network switch to interpret the prefix 
and select the next leg in the path needed to transmit 
the data block on its way to the required STB. 

Thus each disk/network pair's data transmission 
rate is much higher than the STB data block consump- 
tion rate, so that many movie data blocks may be sent 
serially through any MM pair bus during the time that a 
single data block is being consumed by any STB. These 
relative data rates allow each adapter pair to time-multi- 
plex plural concurrently-requested movie data blocks 
serially on the pair bus to the network while all request- 
ing STBs are controlling movies which are being contm- 
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uously viewed on TV sets without any visible 
interruption apparent to their respective viewers. 

Each MM pair may be connected to one or plural 
disks concurrently and independently providing the 
same or different movies to requesting STBs in the net- 
work A multiplexing process is done by the MMC proc- 
essor for controlling a serialization of the transmission 
of the resulting data blocks through the pair bus, since 
the MM pair has only a single pair bus, which is a 
sequential resource that can only transmit one data 
block at a time. 

This serialization on the pair bus is done by the 
MMC processor controlling its issuances of disk com- 
mands to the disk adapter in the MM pair, which controls 
each next disk read operation for the MM adapter pair, 
to allow only one disk data block at a time to be transmit- 
ted to the pair's bus. For example, this serialization may 
be done by enabling the reading of one next disk data 
block to the pair's bus when the end of transmission is 
signalled for the prior disk block's bus transmission. 

The circuits in each MM adapter pair must operate 
fast enough to handle the data blocks coming from its 
disks through the pair's bus, including handling disk 
adapter commands for signalling the read operations 
from the disks and handling the network adapter com- 
mands to set up the required network paths to the STBs 
for the data blocks. One way the network adapter may 
do this is to prefix a path header to each data block 
received from the pair bus before sending it to the net- 
work. 

Accordingly, the MMC and host CPU(s) can concur- 
rently process and provide to the different MM pairs in a 
timely manner a large number of next block commands 
as they are being asynchronously received from a large 
number of requesting STBs. 

Accordingly, a large number of STBs may be simul- 
taneously controlling different movies being viewed on 
different Tvs connected to a large network, as the STBs 
are asynchronously communicating commands to an 
MMC processor on an as needed basis, for which each 
STB command Provides a control block identifying the 
issuing STB and movie requiring service. 

There may be many MMCs in one MM adapter, 
which may be mounted on a single board in an elec- 
tronic box, in which the MMCs are connected to one or 
more I/O buses of a host computer system having one 
or more CPUs. Also many MM adapters may be 
mounted in the electronic box, in which each MM 
adapter may contain many MMCs, with each MMC con- 
necting to a plurality of MM pairs. The MM pairs may be 
mounted on the same or on different circuit boards in 
the same or different electronic boxes as their con- 
nected MMCs. And. those MM pairs may be connected 
to disk drives located in the same or other boxes. Those 
same MM pairs may also be connected to one or more 
networks having paths to thousands of STBs, all inde- 
pendently operating in the "on demand" mode under 
control of a single host computer system to enable the 
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STBs to be independently receiving and controlling con- 
current receptions of movies. 

In the above description of the invention, movies 
are used as an example of a plurality of data files. It is to 
be understood that any type of graphical and/or text 
date files of any size may be handled in place of movie 
data files. 

Likewise, STBs are used as an example of user 
controlled interactive I/O devices; however, this inven- 
tion can likewise be used with other user controlled I/O 
devices such as personal computers, etc. In this man- 
ner, the invention supports "on-demand" data transmis- 
sion to a large numbers of interactive I/O devices. 

Although this invention supports "on demand" 
transmission of data files to all I/O devices connected to 
a network, the invention also supports restricting the "on 
demand" transmission to only a subset of I/O devices in 
the network, to allow other I/O devices in the network to 
operate synchronously for simultaneously receiving the 
same movie (without using the "on demand" feature of 
this invention). The latter case also supports having dif- 
ferent synchronous subsets of I/O devices, in which 
each subset receives a different movie during the same 
time period synchronously within the subset. 

Summary of Drawings 

Figure 1 shows a preferred embodiment of the sub- 
ject invention, which provides a direct connection using 
novel Multimedia (MM) Adapters between storage disks 
and a wide bandwidth distribution network controlled by 
a conventional host computer system which includes 
CPUs, main memory, an Input/Output Subsystem 
(IOSS). 

Figure 2 represents a prior art system which uses a 
host computer system as a data distribution means 
between disk data and interactive network I/O devices. 

Figure 3 shows a preferred embodiment that elimi- 
nates using a host computer system as the data distri- 
bution means between disk data and interactive 
network I/O devices, by off-loading the data distribution 
to one or more Multimedia pairs independently control- 
led by a Multimedia Controller connected to the host 
computer system. Each Multimedia pair contains a disk 
adapter and network adapter that directly distributes 
disk data to a network connected to the I/O devices. Fig- 
ure 3 show a Multimedia Controller and connected plu- 
rality of Multimedia pairs all packaged within one 
Multimedia Adapter. 

Figure 4 shows the control signal flow structure in a 
Multimedia Controller (MMC) contained in any of the 
plural Multimedia Adapters 106 shown in Figure 1. The 
MMC contains a MMC Bus Controller connected to an 
I/O bus 105 of the host computer system. The MMC 
also includes a Controller Bus 405 connected to a plu- 
rality of Multimedia Pairs 409. Each MM Pair Bus 409 
connects a Disk Adapter to a Network Adapter to 
directly pass disk data to the Network Adapter received 
from any disk controlled by the Disk Adapter. The Net- 



work Adapter directly transmits the disk data to an I/O 
device connected to a network. Interactive control data 
received from connected I/O devices is transferred 
through the network adapter to the Controller Bus 405. 

5 Controller Bus 405 connects a MMC processor and a 
MMC Memory to the MMC Adapter Pair Buses. 

Figure 5A shows a MMC Command Control Block 
structure for transferring control command signals 
between a requesting Set-Top- Box (STB), a host CPU, 

io an MMC Processor, and an MMC Processor Memory. 

Figure 5B represents signals used in exemplary 
commands which may be executed in the multimedia 
system. 

Figure 6 is an overall flow diagram of the overall 
15 process used in the system represented in Figure 1 for 
processing each STB request from the network to a 
MMC for delivery, and for interactive control, of a movie 
to be viewed, or while being viewed, by a user at a tele- 
vision (TV) set connected to the STB. Details of the flow 
20 diagram in Figure 6 are shown in Figures 7 through 10. 
Figures 7 and 8 are flow diagrams of processes 
performed in a host CPU for handling a Multimedia Net- 
work System. 

Figures 9 and 1 0 are flow diagrams that represent a 
25 process that runs on a MM for controlling the data flow 
for a movie recorded on a disk to a given STB attached 
to the network. 

Figure 1 1 and 1 2 is a flow diagram of processes 
performed in a STB for making user requests in an "on 
30 demand" Multimedia Network System. 

Detailed Description of the Invention 

Figure 1 illustrates an embodiment of a multimedia 

35 system containing the subject invention. It is controlled 
by a host computer system comprised of a plurality of 
Central Processors (CPUs) 101 which share a host sys- 
tem bus 103 connected to an IOSS (I/O Subsystem) 
104 containing a plurality of I/O Buses 105 A through J. 

40 One or more I/O buses 105 are connected to a plu- 
rality of Multimedia (MM) Adapters 106. Each Multime- 
dia (MM) Adapter 106 is connected to a network 108 
having paths to a plurality of Set-Top-Boxes (STBs) 109 
1 through N. Each MM Adapter 106 is connected to a 

45 plurality of disk drives 1 07. 

The connections of each MM Adapter 106 to the 
disks 1 07 and to network 1 08 are by means of MM Con- 
trollers 302 and MM Pairs 303 and 304 are not shown in 
Figure 1 . But Figures 3 and 4 show the MM Controllers 

so 302 and the MM Pairs 409. Each MM Pair 409 is com- 
prised of items 303 and 304. The host computer system 
(having one or more Central Processors (CPUs) 101 
and main memory 102) is controlled by an operating 
system (OS) software under which Application Code 

55 software and Host Network System software operate. 
All of this software may be executing concurrently in dif- 
ferent CPUs of the host computer system. The Host 
Network System software controls the operation of the 
Multimedia System disclosed herein. 
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Any of the host CPUs can execute (under control of 
a Host Network System program) to pass MM com- 
mands between main memory 102, bus 103, IOSS 104, 
and any I/O bus 105 to any multimedia adapter 106. 

Some of I/O Buses 105 may be connected to con- 
ventional I/O devices, such as disk adapters, tape 
adapters, communications adapters, etc.. while at least 
one of I/O buses 105 is connected to at least one MM 
Adapter pair 106. 

MM network requests generally originate from set- 
top-boxes (STBs) 109-1 through 109-N supporting user 
television (TV) sets, and the multimedia pairs 409 are 
connected to the other end of the network. Any STB 
may send requests (by means of STB commands) to its 
connected multimedia controller 302 through its con- 
nected MM pair 409. 

Each Multimedia Adapter 106 contains at least one 
MM Controller (MMC) 302 shown in Figure 3. Each MM 
adapter 106 may contain any number of MMCs 302, 
and the MMCs may be connected to the same or differ- 
ent I/O bus 105. The I/O bus 105 connects each MMC 
to the host IOSS 104, which stores a command control 
block (sent with each MMC command) into the host 
main memory. . 

Each MMC 302 receives STB requests in the form 
of command control blocks, into which the MMC inserts 
an MMC command and sends it through the connected 
I/O bus 105 (under control of IOSS 104) with an inter- 
ruption signal to the host CPUs. 

If there are plural CPUs in the host computer sys- 
tem, any of the CPUs may accept the interruption signal 
and process the MM request from the MMC. The CPU 
processes the received MMC command and generates 
a corresponding CPU command that responds to the 
MMC command to control the STB requested transmis- 
sion of each block of data from a disk 107 directly to the 
requesting STB 109. without having the disk data pass 
through the host computer system. The CPU process- 
ing checks the authorization of the requesting STB. con- 
trols the billing to the requesting STB, verifies that a disk 
associated with a selected MM pair contains _ the 
requested movie, and if not copy the requested movie to 
such a disk, and processes other related matters. When 
the CPU determines that the transmission of the 
requested movie should be allowed to the STB the 
CPU must sends a responding command to the MMC 
connected to the identified MM pair. 

Generally, the host system (via one of the host 
CPUs) is required to handle movie start and stop com- 
mands The host system need not handle other com- 
mands used in the movie transmission, as they are 
entirely processed by the MMC associated with the MM 
pair performing the direct transmission of movie data 
from the selected disk 107 to the requesting STB 109. 

Thus with this invention, as shown in Figure 1. the 
I/O buses IOSS. CPUs, and electronic memory 
resources of the host system are not used for MM data 
transmission, so that the host computer system is not 
constrained by any MM bandwidth problem (in contrast 



with the prior type of system in Figure 2 where the band- 
width of the host system directly limits the number of 
STBs which can be supported by the host system. 

With this invention, the bandwidths of the buses in 
the host computer system (e.g. host memory bus and 
I/O buses) do not limit the rate of multimedia data trans- 
fers controllable by the host system, in contrast with the 
bandwidth constraint problems being the transfer rate 
limiting factor for the prior MM systems of Figure 2. 
Thus with this invention, the bandwidths in the host sys- 
tem have little affect on the multimedia performance by 
the subject invention. Accordingly, bandwidth con- 
straints in the host system's I/O buses 105 and memory 
bus 1 03 do not affect the flow of disk data to the network 
because it is off-loaded from the CPU and MM adapters 
and MMCs to inexpensive MM pairs 409. Thus, any 
number of MM pairs 409 can be added or deleted later 
(along with any MMCs and MM adapters required to 
support added or deleted MM pairs) in a hierarch.cal 
manner in a MM network to obtain easy scalability of the 
MM network whenever required. 

Accordingly, requested movies need never be 
stored in the host system's main memory 102, except 
perhaps momentarily in a process of copying a movie 
from one tape or disk to a disk associated with the MM 
pair which is to handle the data transmission m the proc- 
ess of executing a start movie command. 

Thus the invention supports "on-demand" trans- 
mission of data in the same or different data files (e.g. 
movies) to any network connected STB. "On demand 
transmission enables each STB to independently con- 
trol its reception of a copy of movie or other multimedia 
file For example, each STB may start its reception of a 
movie at any time it wishes, so that its reception need 
not start simultaneously with the reception of any movie 
by other STBs. Any receiving STB may be fast-forward- 
ing or rewinding, its received copy of a movie, while 
other STBs may be viewing a different part of the same 
movie or doing any VCR-type control function with it. 

Figure 3 shows a layout of a multimedia adapter 
(MM A) 106. It contains at least one multimedia control- 
ler (MMC) 302. and may contain a plurality of MMCs. 
Each MMC is connected to one of the host's I/O buses 
105 and more than one MMC may connect to the same 
I/O 'bus 105. Thus. MMA 106 may contain as many 
MMCs 302 as the host system needs to control all STBs 
on all networks assigned to the host system. Generally, 
a host system in a large central electronic complex 
(CEC) has the processing power needed to control a 
very large number of STBs (e.g. thousands, because 
the volume of commands to/from the host CPUs from 
the MMCs 302 will likely require only a small amount of 
host processing power. 

Each MMC 302 is connected to and controls one or 
more multimedia pairs (MM pairs) 409 which contains 
one disk adapter 303 and one network adapter 304. The 
number of MM pairs connected to one MMC is deter- 
mined by the total number disk drives and STBs which 
must be supported concurrently by the MMC processor. 
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The number of disk drives controlled by an MM pa 
ir 409 is related to the maximum number of STBs which 
can have data blocks serially transmitted fast enough 
over the connected MM pair bus to maintain continuous 
viewing of their respective movies at the receiving 5 
STBs, which is determined by the lesser of the disk or 
network adapter bandwidths since the adapter pair bus 
will be implemented to have a bandwidth greater than 
either the disk or network adapter. 

Figure 4 represents a preferred embodiment of an 10 
MMC 302. It is connected to one of the host's I/O buses 
105 through MM bus controller 404 in the MMC 302. 
The MMC 302 also contains a MMC processor 401 and 
a MMC memory 403 which are also connected to the 
MM controller bus 405. MMC processor 401 may be a is 
conventional microprocessor. 

The plurality of MM pairs 409-1 ... 409-N are also 
connected to controller bus 405; any number of pairs 
409 may be connected to bus 405 through respective 
control bus extensions 408. Each control bus extension 20 
408 connects through MM pair bus 402 to a conven- 
tional adapter control bus 406 in the disk controller 303 
and to a conventional adapter control bus 407 in the net- 
work controller 304 in each MM pair 409. 

Each MM pair 409 includes a disk adapter 303 and 25 
a network adapter 304. The disk adapter 303 connects 
to and controls one or more disks 107 (see Figure 1). 
The network adapter 304 connects to network 108. 
Each disk adapter 303 may be a conventional disk con- 
troller for controlling a plurality of disks 107. Each net- 30 
work adapter 304 also may be a conventional network 
controller that connects network 108 to MMC 302. 

Command signals between MMC processor 401 
and each MM pair 409 are sent through bus 405 and its 
extensions 408 to/from a respective adapter control bus 35 

406 or 407 in any MM pair 409 addressed by the com- 
mand. STB requests (in command control blocks) are 
transmitted from a STB through a network adapter bus 

407 of an associated MM pair 409, and through its bus 
extension 408 and MMC bus 405, from which the STB 40 
command control blocks are stored in the MMC mem- 
ory. A MMC transfer-control command is sent by the 
MMC processor to the MM pair 409 receiving the corre- 
sponding STB command for each data transmission on 
the MM pair bus 402 requested by an STB. 45 

The MMC processor receives all STB commands 
and handles them in first in first out (FIFO) order. This 
execution order by the associated MMC processor 401 
controls the sequence of data transmissions through 
each associated MM pair bus 402 to all STB requestors so 
of service to the associated MMC. The rate of command 
processing by the MM processor must stay ahead of the 
data transfer rate in each associated MM pairs 409, 
which must be fast enough to maintain continuous view- 
ing of the movies at the Tvs connected to the requesting ss 
STBs. The maximum number of MM pairs 409 which 
can be handled by each MMC 302 is affected by the rate 
that the MMC processor can respond to the MM pairs 
with data block commands. STB requests for next the 



data block are sent through bus 402 to the MMC proc- 
essor between data block transfers on bus 402 under 
control of an interruption signal received from the STB 
with each request. 

Figure 4 describes in more detail the multimedia 
controller (MMC) 302. The MMC 302 controls the read- 
ing of data (e.g. a movie) from a disk and delivers the 
data to the network via the network controller. 

The MMC processor executes a control program 
stored in the MMC memory 403 to perform its network 
control functions. A MMC processor command controls 
disk controller's reading of data from its associated 
disks for the data to be sent over the pair bus 402. 

The disk adapter 303 and network adapter 304 
should have data transfer rates that match the rate for 
the pair bus 402 and the network transmission rate to 
the STB. Therefore the movie data rate for the data 
blocks flowing from a disk through the network adapter 
304 will move at the lesser of the data rates supported 
by the pair of adapters 303 and 304. The maximum rate 
of data traffic on one pair bus 402 is the limiting factor in 
determining the maximum number of STBs which can 
be supported by one MM pair 409. 

The speed at which the MMC processor 401 sends 
data transfer commands to the adapter pairs therefore 
controls the simultaneous data transmissions on the dif- 
ferent pair buses 402 associated with the MMC. 

A disk switch (not shown) may be connected 
between any disk and any disk adapter 303 in the differ- 
ent MM pairs 409. The disk switch enables the disk to 
be switched to any of plural disk adapters. Such disk 
switching enables a CPU to associate a disk (when 
required by a STB command) to an MM pair 409 
required to perform the data transfer. Also, network 
switches may switch a network adapter 304 to a 
requesting STB required by a command. 

Thus, a vast number of multimedia data transmis- 
sions may be simultaneously controlled by a single host 
computer system connected to one or more MM adapt- 
ers, each containing one or more MMCs, and each 
MMC containing one or more adapter pairs 409. 

Consequently, the total bandwidth enabled by this 
invention's use of plura! data transfer buses (pair buses 
402) may support multimedia data transmissions for a 
very large number of "on demand" STBs, which may far 
exceed (by an order of 100s or 1000s) the bandwidth 
resources found in any large mainframe computer sys- 
tem. 

Figure 5A represents a structure for Command 
Control Blocks used by the STBs, MMCs and CPUs for 
controlling STB requested operations. This command 
block is generated by any STB and sent to an MMC 
processor 401 which processes it, and also may pass it 
to the host computer system if it is a movie start or stop 
command. 

Start and stop commands are also handled by the 
host computer system under a network control program 
stored in the host main memory. Other commands may 
not use the host system, and they may be executed 
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solely by the MMC processor 401 using another net- 
work control program stored in the MMC memory 403. 
These programs control the execution of commands in 
the respective processors. These programs may be 
backed up on, and be paged from, one of disks 1 07. - 

A command processor in the MMC network control 
program processes the MMC commands and controls 
disk controller 303 and network controller 304 in each 
selected MM pair. Thus, the command processor may 
process a command control block received from a STB. 
and issue an MMC command to one of its disk adapters 

303 to initiate the reading of a block of data of a 
requested movie stored on a selected disk 107. A corre- 
sponding network command may be concurrently gen- 
erated and issued to the associated network adapter 

304 to transfer the disk read data block from disk 
adapter bus 406 through pair bus 402 to network 
adapter bus 407 which sends the data block over the 
network to the addressed STB. 

The STB send next block commands to network 
adapter 304 which forwards these commands to the 
MMC processor, which then generates the MMC com- 
mands for the next data block and sends them to disk 
adapter 303 and network adapter 204 until all data 
blocks in the movie have been transmitted. The com- 
mand control program may control the transfer of disk 
data according to any current network protocol, such as 
by sending it in data packets. In this manner, the data 
will flow directly from any disk to the connected network 
to the requesting STB, without using any data transfer 
resource in the host computer system or in any MMC 
processor. 

Therefore with this invention, the maximum amount 
of multimedia data which can be controlled by a host 
computer system has NO relationship to the amount of 
multimedia data which can be transferred under control 
of the host computer system. And, the MM command 
traffic in the host computer system for controlling the 
multimedia data transfers may require an insignificant 
amount of the resources of the host computer system. 
Accordingly, the host computer system operation may 
not be significantly affected by the multimedia data traf- 
fic on any or all of the paired data buses 402. Therefore 
most of the time, the host computer resources may be 
used for data processing operations unrelated to the 
MM operations. 

The Command Control Block structure in Figure 5A 
encapsulates signals used in all commands in the pre- 
ferred embodiment. Figure 5B indicates the fields used 
in the command control block by placing a "valid" to rep- 
resent each field used in a command. Columns 2 
through 7 (from the left in Figure 5B) each represent a 
different type of MM command, and column 7 repre- 
sents all STB user commands. Column 1 in Figure 5B 
names the fields used by the commands represented in 
the other columns, except for the "direction" which indi- 
cates the direction of transfer (between the MMC proc- 
essor and host or STB) for each command represented 
in columns 2-7. 
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The command control block is generated by any 
STB when it requests a service from the system. The 
control block is then transmitted from the STB over the 
network through the network adapter 304 in its MM pair 
409 to the MMC processor 401 . 

In generating the control block, the STB places 
entries in control blockfields: "destination" 504 receives 
the requestor's network address, "file identifier" 506 
receives a movie number, and "requestor command" 
507 receives the operation requested. In advanced 
designs of STBs, only the latter two f ield 506 and 507 
need be keyed into the STB by the user, and the former 
field 504 is automatically placed by programming in the 
STB since its address is always the same for a given 
STB. The programming in the STB formats the contents 
in all of these fields. 

All MMC commands are initiated by a user request 
command (see column 7). If the user wants to see a 
movie, the user keys information into the STB for at 
least the file identifier field 506 and requestor command 
507. The STB generates a command control block con- 
taining this information (see column 4) adds the destina- 
tion 504 and then sends the control block with an 
interrupt signal as a user request command to the MMC 
memory The MMC processor fetches this block from its 
memory and inserts an MMC request movie command 
in the MMC command field 502 and sends it with an 
interrupt signal to the host system main memory. A CPU 
in the host system accepts the interruption, reads the 
block from the host main memory, inserts a start movie 
command in field 501 , and performs processing needed 
to be done before any movie can be transmitted to any 
STB. 

The CPU processing includes checking if the STB 
is authorized to receive the requested movie. To do this, 
the CPU looks up the STB in an authorization table in 
the CPU's main memory. If the user is found to be 
authorized, the CPU places a start movie command in 
the host command field 501. a movie start location in 
the source field 503, length of movie in byte length of file 
field 505 and sends the block to the MMC with an inter- 
rupt signal. The start movie command requests the 
MMC processor to send the first disk command to a disk 
adapter 303 in a selected pair 409 to start the transmis- 
sion of the first data block of the identified movie to the 
network and the STB address in the command control 
block The MM disk adapter 304 executes the disk com- 
mand to read the first data block and sends it to the net- 
work adapter 304 via the pair bus 402 which sends it to 
the requesting STB. 

A STB stop command also requires CPU process- 
ing to de-allocate the disk from which the movie trans- 
mission was made. , . 

STB "inter-transmission commands" are issued Dy 
an STB while the MMC is handling a movie transmis- 
sion (i e. between the starting and stopping of a movie 
transmission). Most inter-transmission commands do 
not need CPU processing, since they can rely on the 
authorization and other CPU services performed in exe- 
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cuting the start command as a prerequisite for the 
movie transmission. Examples of inter-transmission 
commands simulate well-known VCR functions, e.g. 
Fast Forward, Rewind, Pause, etc. These inter-trans- 
mission commands are user explicit commands (require 
keying by the user at the STB). 

An implicit type of STB command is the "next block" 
command which is not keyed by, or other wise known to 
the user, but is automatically issued by programming (or 
circuits and/or microcode) in the STB for requesting 
each next block of data in the movie in time to maintain 
continuous viewing of the movie on the associated TV 
screen. The sending of each next block command is 
triggered by STB circuits (or microcode) which sense 
when the current data block being outputted by the STB 
to the TV has reached a point where the next block must 
be requested early enough to allow time to receive it for 
maintaining continuous viewing. 

Cooperating network control programs (NCPs) in 
the host system and in the MMC storage perform differ- 
ent phases of interpretation on the fields in each com- 
mand control block when it is being handled by a host 
CPU by the MMC processor 401 . For example, the NCP 
processes a start command by a CPU checking the 
requesting STB's authorization, and determining if the 
STB is authorized to view the requested movie. If the 
CPU finds the STB is authorized, the CPU determines 
which disk contains the movie. If no disk has it the CPU 
copies the movie from tape to one or more disks asso- 
ciated with the MM pair 409 which is to handle the 
movie transmission. When the disk address is deter- 
mined for the disk containing the movie, the CPU stores 
the disk address in the command's control block source 
field 503 and passes the control block to the MMC stor- 
age and sends an interrupt signal to the MMC proces- 
sor to have it continue execution for the command. Then 
the MMC processor then executes the MMC's NCP to 
generate commands for the selected adapter pair 409 
to control the transmission by the selected disk contain- 
ing the requested movie specified in field 503 in the con- 
trol block, and sends the commands to the selected 
adapter pair to start the transmission of the first data 
block of the movie to the STB indicated in the control 
block. 

Thus MMC NCP interprets the fields in the com- 
mand control block including the MMC command field 
502, the File Identifier field 506 that identifies the 
requested movie, source field 503 containing the disk 
address which identifies the disk 1 07 and addresses the 
requested movie, length of the movie 505, and the STB 
destination 504. The NCP executed by the MMC proc- 
essor then generates the commands for the adapter 
pair which will transmit the movie to the requesting STB. 
This NCP contains a predetermined size for each data 
block to be transmitted from a disk to the network, and 
the NCP uses the length field 505 (containing the 
number of bytes to be transferred in the movie) to deter- 
mine when a command to the adapter pair is for the last 
data block of the movie to be transferred from the disk to 



the network, since it requires special operations. Desti- 
nation field 504 (containing the STB Network Address to 
which the adapter pair 409 sends data blocks of the 
movie) is placed by the MMC processor into the com- 
5 mand to the network adapter in the selected adapter 
pair. 

The MMC NCP also processes the VCR-like STB 
requests. For a rewind request, it skips over a predeter- 
mined number of previous data blocks in determining 

io the disk address (pointer) for the next data block to be 
transmitted. For a fast forward request, it skips over a 
predetermined number of later data blocks in the movie 
for determining the disk address (pointer) for the next 
data block to be transmitted. For a pause request, it 

is repeats the pointer to last sent block in the movie for 
determining the disk address (pointer) for the next data 
block to be transmitted until the pause request is ended, 
and internal controls in the STB operate the pause 
effect on the TV screen. 

20 Each transmitted data block contains both display 
and sound information which is provided to the STB for 
the attached TV set. 

Figure 1 1 shows the control flow performed by an 
STB processor in each Set Top Box (STB) in the net- 

25 work for providing each user request. Steps 1101 
through 1104 perform processor functions carried out 
when a user physically keystrokes commands to the 
STB - on a STB panel or on a STB remote control 
device (which may be on the TV's remote control 

30 device). Each STB command generates an interrupt 
and a command control block of the type shown in Fig- 
ure 5A. The interrupt signals an interruption to a control 
program being executed in the STB so that the process 
in Figure 1 1 can be performed by the STB processor. In 

35 step 1 101, the Destination Address is set into field 504 
which is the address of this STB in the network. Step 
1 102 sets the requestor command into field 507, which 
may be a Start, Stop, Play, Pause, Fast Forward, or 
Rewind request for a movie. Step 1 103 sets File Identi- 

40 fier field 506 with the identifier (ID#) of the desired 
movie. Steps 1 1 0 1 , 1 1 02 and 1 1 03 may be performed in 
any order in addition to the illustrated order. 

In step 1104 the command control block is then 
sent over the network to the assigned MMC Processor 

45 where the command is serviced by the process shown 
in Figures 9 and 10. 

Figure 12 shows the process performed in any STB 
to play a received movie on an attached Television (TV) 
set. The movie being received by an STB plays continu- 

so ously on the TV set attached to the STB. Step 1 201 rep- 
resents each received data block, which is buffered in 
the STB as it arrives, and a data block may contain 
many TV data frames. Each frame of data is then read 
out of the buffer by step 1 202, and step 1203 checks the 

55 buffer after each frame to see if it is the last frame of the 
buffered data block. If not the last frame, a backward 
loop branch is taken to step 1 202 to read the next frame, 
until all frames are read. If step 1203 detects the last 
frame of a buffered data block, then steps 1204 through 
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1 206 inform the MMC to send the next da a block of the 
movie until the last frame is detected. Step 1204 sets 
the Destination field 504 in the , control b.ock_ step 1205 
sets the Requestor Command .n fie d 507. and step 
1206 sends the control block to the MMC. 

Fiqure 6 represents the general control process for 
execuJng commands in the multimedia controller 
(MMC) and a host system CPU after a user ,n.t.ates a 
command at a STB. In step 601. a user requests an 
user-identified movie be transmitted tc , »« . user s sm 
usuallv by keystrokes to the STB. The STB sends a 
miie start revest as an requestor command through 
^network to the network adapter 304 to wh.ch the 
STB is currently connected. 

Each STB contains a processor wh.ch provdes a 
command control block of the type shown in Figure £A 
containing a user request for a mov.e in the requestor 
S 507 and the STB inserts a movie identrf.er m the He 
dentifier field 506 for the desired mov.e keyed to the 
STB by the STB user. The STB processor also sets into 
Sds1o4 in the command control blocK the .destmation 
address (the STB network address). The STB then 
sends *e control block as its request to its connected 
MMC where the command block is further processed 
oTthe MMC in step 602 (shown in detail ,r iFpres 9 
and 10) The MMC processor rece.ves this control block 
an2 acknowledges it by setting field I 50= : wrth an 
acknowledge command, writing the changed control 
block in its memory, and sending a copy of this b ock :Xo 
the requesting STB. The MMC then sends an .n tern* 
signal and a copy of this control block to a CPU 101 fo 
STer processing in step 603. A start request does not 
send movie data to the STB the f irst time the command 
fs received by the MMC. because the STB has not yet 
been approved to get the movie. 

In step 603, the CPU processes the control block 
using the process shown in Figures 7 and 8. In A rt** 
the CPU validates the STB user (determines h.s bill. 6 
paid etc.). sets command block source field 503 and f e 
length field 505 after looking up this 'n'°™at.on 'n 
tables in the host main memory 102. Hence, rf the CPU 
Ss the movie is not on any of the disks available to he 
MMC pair 409 handling the STB request the CPU can 
copy the movie from tape to an ava.lable disk .n that 
mSc pair 409, or the CPU may copy the mov.e 1 on a 
disk connected to another MMC pair 409 If the CPU 
finds the requesting STB is not authorized (such, as rf . ts 
user did not pay prior billings), then «ie STB ^reque « « 
terminated. If these tests are sat.sf.ed, tt« > move ms 
approved for viewing by the requesting STB and the 
CPU then sets the host command f ield 501 and sends a 
command interrupt to the MMC which 
ess it The MMC processor then controls the move data 
transmission to the STB by going to step 604 _ 

This time through step 604, the process takes path 
A to Figure 10 from Figure 9 and the data transm.ss.on 
is started to the STB. Here, the process also anafyzes 
the control block for more detailed instruct.ons from the 
use suS as whether this is a VCR type of command 



(rewind, fast forward, pause, play, stop, etc). H so the 
MMC inserts a corresponding MMC command that «H 
be effective to initiate and perform the requested open, 
ton at the STB processor. While this is going on the 
5 MMC s checWng'for interrupts from the CPU and from 
5 ^connected STBs via the network, and concurrently 
may be doing work for other requests. 

In step 605. the movie is sent in a sequence of data 
blocks, as'the STB plays out its current block of data 
,o and makes a next command for the 

the movie, performed in Figures 7 and 8. In step 606^ 
he CPU processes the movie complete command and 
updates workload tables as shown in Figures 7 and 8. In 
sS * 607 the CPU processes the acknowledgemen 
, 5 SS, found in the MMC command field in the control 
block passed from the MMC; this completes the ^ing 
for the requested movie. This completes the MMC/CPU 

Z o by the host system. When a CPU interrupt ,s sent from 
th'e MMC processor to the CPU. an associated com- 
mand control block is stored in the main memory o *» 
CPU. and (based upon which valid command .t .s), its 
specific functions are carried out. 
25 In step 701 and 702, the MMC command block is 
read and field 502 is checked to see if -t contains an 
Sk Command. If this is the case, the billing for the 
feauest is performed in step 703. This billing is an 
aSoSing procedure for billing the user at the destina- 
30 tTaddrels'in field 504. Once the 

the CPU returns from the interrupt in step 708 where .t 
returns to its interrupted processing operations, and the 
CPU may not perform any MMC work until a next inter- 

ruptfrom a MMC. - , , ^ lcac+ 

35 The MMC signals the CPU when it fetches the Mast 
data block of the requested movie wh.ch the CPU 
"e ectsTn step 704 (following step 702 finding .that *. 
MMC command is not an acknowledge command)^ if in 
Sap 704 the command indicates the mov.e transm.s- 
4 o X is complete, the CPU enters step 705 to update * 
workload tables to balance the workload on the 
resources in the system, such as the CPUs and the 
MMCs After this is done, the CPU process.ng is com- 
SfoTthe current interrupt, and step 708 causes the 
« CPulo return to its prior processing which it was doing 
when interrupted for the current multimedia command. 

Step 706 checks if the command is a new STB 
recuest which is handle by entering the process .n F.g- 
u^e 8. Only new STB command requests should .reach 
so step 706 in this processing path. If it is not a new STB 
fewest, then the command is considered invalid and an 
elr must be posted by the CPU and a .ntom 'from 
interrupt to step 708 is again taken to .nd.cate to the 
TcSox that it should continue its last process.ng 
5S 'which was interrupted to perform the 

processing If the command is a new request, the proc 
esStolnues on to handle this request by go.ng to 
the process described in Figure 8. 
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Figure 8 shows the CPU control when a Movie 
Request command is received at the CPU. in the control 
block for this command, the user has inserted Destina- 
tion field 504, which is must be validated by step 801. 
Once this is accomplished, the Movie 1D# in field 506 is 
checked by step 801 to see if the movie resides on a 
disk, if the movie is not presently on any disk in the 
MMC pair connected to the requesting STB, then the 
movie must be copied by step 803 from tape to disk. As 
soon as the movie exists on a disk controlled by the con- 
nected MMC pair 409, the MMC processor can proceed 
in sending the movie data to the requesting STB; the 
disk copying operation need not be complete before 
proceeding to send the movie. 

Once it is determined that the movie resides on 
disk, the host's load balancing tables must be checked 
by step 804. These tables keep track of the number of 
users accessing specific movies and the number of cop- 
ies of each of the movies is being delivered by the 
respective MMC pairs, so as not to cause any bottle- 
neck in the delivery of new movie requests. If there is 
not a copy of the movie on a disk able to be used for this 
request, then the movie must be replicated by step 805 
by copying it from a disk controlled by another MMC pair 
409. After the CPU has established which MMC disk will 
deliver the movie, the load balancing tables must be 
updated by step 806. 

Next more fields in the command control block must 
be set before it can be sent to the selected MMC. This 
entails writing and copying specific information by steps 
807, 808, 811 respectively in source field 503 and in 
length field 505. Also field 501 is set with the host com- 
mand (501) to indicate a Start Movie operation. Then 
step 812 issues the command to the selected MMC, 
and step 813 returns the processor operations from the 
current interrupt processing in Figure 8. 

Figure 9 describes the flow of control within the 
MMC processor. The MMC processor may be inter- 
rupted by either the CPU or an STB request. If the inter- 
rupt is signalled by a CPU, the CPU stores the 
command control block in the CPU memory 102 from 
which it is fetched by step 902 from CPU main memory 
102 to the MMC processor memory 403. Once the con- 
trol block is read into the MMC memory 403, the MMC 
must acknowledge that it has received the control block. 
This is accomplished by step 904 setting the MMC 
Command field 502 to an ACK indication. Then, the 
updated control block is written by step 905 to the CPU 
main memory, and then the CPU is interrupted by step 

906 for the CPU to process the command block. 

Now the host command field 501 is checked by step 

907 for an indication of whether it indicates a stop movie 
command. If step 907 indicates the command is a stop 
command, the processing halts any further data deliv- 
ery operation for the movie to the requesting STB. To do 
this, step 914 is entered to set a halt operation com- 
mand in the MMC command field of the control block to 
indicate the movie transmission is complete, and then 
step 915 stores the the control block in the CPU's main 



memory, while step 916 send an interruption signal to 
the host system to look at this control block. The inter- 
rupt signal is serviced by a next available host CPU 
accessing the control block and posting CPU movie 

5 management tables to indicate the movie transmission 
is halted to the receiving STB. Also, the CPU updates 
host workload balancing tables for maintaining optimum 
system performance - such as by switching STBs to dif- 
ferent MMC pairs 409 when STB requests are being 

10 delayed, so that a minimum transmission delay is main- 
tained in the data transmission servicing of the request- 
ing STBs by the different MMC pairs 409. 

When step 907 indicates the command is not a stop 
command, step 908 tests the CPU for being a start com- 

15 mand. If step 908 finds it is not a start command, then 
the host command is other than a stop or start com- 
mand, and then step 912 indicates it is an invalid host 
command for the current processing path, and step 910 
is entered, which causes it to return to its prior inter- 

20 r upted process! ng . 

When the MMC processor returns from interrupt in 
step 910, it goes into a wait state to wait for a next inter- 
rupt from either a CPU or a STB to start its next 
processing operation. The wait state may be maintained 

25 for the MMC processor by having it enter a wait loop, 
until it receives a next interrupt signal from a CPU or a 
STB. 

Figure 1 0 is a detailed flow diagram of operations in 
the MMC processor when a request is received from an 

30 STB in a command control block along with an accom- 
panying interrupt. Each request is sensed by step 901 in 
Figure 9, which takes its yes exit to step 1001 in Figure 
10. Then step 1001 takes its yes exit to step 1015 if the 
requestor command 507 is a new request in which the 

35 MMC processor sets command field 502 in the com- 
mand control block to request movie; and the following 
steps 1016 and 1017 write the command control block 
into host main memory and interrupt a CPU to service it. 
If step 1 001 finds the command block does not con- 

40 tain a new request, its no exit is taken to step 1002 to 
test the control block for containing a stop command. If 
it contains a stop command, then the movie transmis- 
sion is completed by setting the MMC command field to 
movie complete to indicate a stop command in the con- 

45 trol block. Then steps 1015, 1016 and 1017 operate in 
the manner previously described the control block is 
sent to the CPU as previously described to put the MMC 
processor into wait state to awaits its next interrupt. 
If the STB Command is not a start or stop com- 

so mand, step 1 003 is entered to test the command block 
for containing aFast Forward command in the requestor 
command field 507. If not a fast forward command, 
Rewind test step 1004 is entered. If step 1003 finds it 
contains a fast forward request command, step 1011 

55 moves a pointer (or other indication) to obtain, or gener- 
ate, a next data block in the transmission of the current 
movie to the STB. If step 1004 finds it contains a rewind 
request command, step 1012 moves the pointer (or 
other indication) backward to obtain, or regenerate, the 
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prior transmitted data block which is then retransmitted 
to the STB to replay the prior data in the ™*e. ™en 
step 1018 is entered to put the MMC processor ,nto rts 
wait state as previously explained herein. 

H step 1004 finds the control block does not contain 
a rewind command, step.1005 is entered 
trol block for an STB pause request. If the STB Com 
mand has a Pause request, then the MMC processor 
does not perform any further data transmissions to the 
STB and this is done by simply returning the MMC 
processor to its wait state by entering the return from 
interrupt step 1018. previously explained herein. 

If step 1005 f inds the command block does not con- 
tain a pause command, step 1006 is entered to test for 
a play command in requestor command field 507 If no 
p ,ay command is in the block, step 1007 is entered^ 
which looks for a "next data block" command indicator, 
in field 507. If either a play command or a next block 
command is found, step 1013 is entered tc , cause h 
next data block to be transmitted on the network to the 
reouesting STB to continue the movie transmission. If 
s5 P To 4 finds this is not the last block, steps 1018 -s 
executed, as previously described, to put the MMC 
processor into the wait state. 

If step 1014 finds this is the last block, steps 1015 
through 1018 are executed to put a movie complete 
command in MMC command f ie.d 502. store the contro 
block in the host main memory, and interrupt the host 
processor and returns from interrupt. 

If step 1007 finds this is not a next data block 
request command, then the content of the command 
block has been tested for all possible commands and 
none has been found. Then an invalid command .s 
being processed, and step 1008 is entered which 
passes control to step 1018 that puts the MMC proces- 
sor into a wait state. 

It should be understood that the embodiment 
described herein has been provided by way of example 
and not by way of limitation, in light of the forego.no 
description, many modifications and variat.ons which do 
not depart from the scope and spirit of the invention is 
defined by the appended claims. 

Claims 
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A hierarchical multimedia (MM) distribution system 
for supporting "on demand" control of graphical 
data files being received by viewing-control devices 
connected to a network, comprising: 

a host computer system for monitoring the MM 
distribution system, 

the MM distribution system comprised of a plu- 
rality of MM adapters connected to the host 
computer system, 
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each MM adapter containing one or more MM 
controllers, each MM controller containing a 
controller bus connected to an MM processor, 

one or more MM pairs connected to the control- 
ler bus. 

each MM pair including a disk adapter and a 
network adapter, the disk adapter connected to 
one or more disk drives for receiving data 
blocks read from selected disk drives, graphical 
data files being stored on the disks, and data 
blocks in a requested data file being read 
directly from each selected disk to the disk 
adapter, 

a pair bus in each MM pair for directly receiving 
the data blocks received by the disk adapter 
and for directly transmitting the data blocks to 
the network adapter, 

the network adapter in each MM pair directly 
distributing the data blocks from the pair bus to 
the network, each data block being addressed 
to any viewing-control device requesting a data 
file containing the data block, and 

means in each viewing-control device for issu- 
ing interactive commands through the network 
to the network adapter to control characteris- 
tics of data reception of the requested data file 
being transmitted to the viewing-control device. 

A hierarchical multimedia (MM) distribution system 
for supporting "on demand" control of graphical 
data files being received by viewing-control devices 
connected to a network as defined in claim 1, the 
command means at the viewing-control device 
comprising 

means for generating a control block having a 
field for containing a command being 
requested by the viewing-control device, and 

means for sending the control block through 
the network to the connected network adapter 
and transferring the control block to an associ- 
ated MM processor for the MM processor to 
receive the command. 

; A hierarchical multimedia (MM) distribution system 
for supporting "on demand" control of graphical 
data files being received by viewing-control devices 
connected to a network as defined in claim 1 . fur- 
ther comprising 

the viewing-control devices being set-top- 
boxes (STBs) connected to viewing devices 
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respectively comprising television (TV) sets, 
and 

commands being keyed into the STBs by view- 
ers of the TV sets. $ 

A hierarchical multimedia (MM) distribution system 
for supporting "on demand" control of graphical 
data files being received by viewing-controi devices 
connected to a network as defined in claim 1 , fur- io 
ther comprising 

at least some of the graphical data files con- 
taining both audio and visual information. 

15 

A hierarchical multimedia (MM) distribution system 
for supporting "on demand" control of graphical 
data files being received by viewing-controi devices 
connected to a network as defined in claim 2, fur- 
ther comprising 20 

movies comprising at least some of the graphi- 
cal data files. 

A hierarchical multimedia (MM) distribution system 25 
for supporting "on demand" control of graphical 
data files being received by viewing-controi devices 
connected to a network as defined in claim 1, fur- 
ther comprising 



30 



35 



I/O channels in the host computer system con- 
necting the MM adapter bus to the host compu- 
ter memory, 

commands from any viewing-controi device 
being sent to the network adapter and for- 
warded to the connected MM processor for 
processing. 



7. A hierarchical multimedia (MM) distribution system 40 
for supporting "on demand" control of graphical 
data files being received by viewing-controi devices 
connected to a network as defined in claim 2, fur- 
ther comprising 

45 

a start command being interpreted by the MM 
processor and forwarded to the host computer 
system for determining authorization by the 
viewing-controi device to receive a data file 
requested by the start command, and the host so 
computer system signalling the MM processor 
that the requested data file is not to be sent to 
the requesting viewing-controi device. 

8. A hierarchical multimedia (MM) distribution system 55 
for supporting "on demand" control of graphical 
data files being received by viewing-controi devices 
connected to a network as defined in claim 2, fur- 
ther comprising 



a start command received by the MM proces- 
sor and transferred to the host computer sys- 
tem for determining authorization by the 
viewing-controi device to receive a data file 
requested by the start command, and the host 
computer system signalling the MM processor 
that the requested data file is to be sent to the 
requesting viewing-controi device because an 
attached viewing device is found authorized to 
receive the data file. 

9. A hierarchical multimedia (MM) distribution system 
for supporting "on demand" control of graphical 
data files being received by viewing-controi devices 
connected to a network as defined in claim 8 t fur- 
ther comprising 

a stop command being processed by the MM 
processor and forwarded to the host computer 
system for processing transmission-termina- 
tion information for the viewing-controi device, 
and the host computer system signalling the 
MM processor to stop reading and sending 
blocks of the requested data file to the viewing- 
controi device. 

10. A hierarchical multimedia (MM) distribution system 
for supporting "on demand" control of graphical 
data files being received by viewing-controi devices 
connected to a network as defined in claim 2, fur- 
ther comprising 

a next-block command being sent by the view- 
ing-controi device to the MM processor before 
a last block received by the viewing-controi 
device has been completely transmitted by the 
viewing-controi device to the TV set, and 

the MM processor responding to the next-block 
command by transmitting any next block in the 
data file for reception by the viewing-controi 
device before the last block has been com- 
pletely transmitted by the viewing-controi 
device to the TV set. 

11. A hierarchical multimedia (MM) distribution system 
for supporting "on demand" control of graphical 
data files being received by viewing-controi devices 
connected to a network as defined in claim 2, fur- 
ther comprising 

a next-block command being sent by the view- 
ing-controi device to the MM processor to 
request a next data block when each data block 
is received and stored in a buffer at the view- 
ing-controi device while a last-received data 
block is being read and processed by the view- 
ing-controi device from another buffer. 
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12. A hierarchical multimedia (MM) distribution system 
for supporting "on demand* control of graphical 
data files being received by viewing -control devices 
connected to a network as defined in claim 1 1 or 
12, further comprising 

the MM processor testing for no last block 
being available from the data file in response to 
receiving each a next-block command as part 
of the processing of the command by the MM 
processor, and 

the MM processor inserting a data file end sig- 
nal in the command and sending the command 
to the host computer system for termination 
processing of the data file for the viewing-con- 
trol device. 

13. A hierarchical multimedia (MM) distribution system 
for supporting "on demand" control of graphical 
data files being received by viewing-controf devices 
connected to a network as defined in claim 2, fur- 
ther comprising 

a viewing-control command being sent by the 
viewing-control device to the MM processor to 
request a change in the viewing presentation at 
the viewing-control device, and 

. the MM processor controlling a selected disk to 
select the next block in a data file to be sent to 
the viewing-control device according to a con- 
trol indication put in the command-control block 
by the viewing-control device. 
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A hierarchical multimedia (MM) distribution system 
for supporting "on demand" control of graphical 
data files being received by viewing-control devices 
connected to a network as defined in claim 13, fur- 
ther comprising 



data f iles being received by viewing-control devices 
connected to a network as defined in claim 13, fur- 
ther comprising 

a fast-backward (rewind) command indication 
being provided in a command control block 
sent to the MM processor as the viewing-con- 
trol command, 

the MM processor receiving the fast-backward 
command and controlling a selection of a back- 
ward data block by backward incrementing the 
data file by a predetermined number of data 
blocks from a last data block transmitted to the 
viewing-control device, and 

the MM processor continuing transmission of 
the data file to the viewing-control device from 
the backward data block. 

A hierarchical multimedia (MM) distribution system 
for supporting "on demand" control of graphical 
data files being received by viewing-control devices 
connected to a network as defined in claim 13, fur- 
ther comprising 

a pause command indication being provided in 
a command control block sent to the MM proc- 
essor as the viewing-control command, 

the MM processor receiving the pause com- 
mand terminating further transmission of any 
data block in the data file to the viewing-control 
device until a no-pause command is received 
from the viewing-control device, and 

the viewing-control device repeating a reading 
of data from a buffer for a last picture displayed 
by an associated viewing device. 



40 



a fast-forward command indication being pro- 
vided in a command control block sent to the 
MM processor as the viewing-control com- 
mand, 45 



the MM processor receiving the fast-forward 
command and controlling a selection of a for- 
ward data block by forward incrementing the 
data file by a predetermined number of data 
blocks from a last data block transmitted to the 
viewing-control device, and 



50 



the MM processor continuing transmission of 
the data file to the viewing-control device from 
the forward data block. 

15. A hierarchical multimedia (MM) distribution system 
for supporting "on demand" control of graphical 
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